Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Using unnamed widget pools

Any unnamed widget pool you create becomes the default pool until it is deleted or until you create another unnamed pool. Any unnamed pools you create are scoped to the routine in which they are created. This routine can be a main procedure block, an internal procedure, or trigger block. A subprocedure or trigger inherits, as its default pool, the most recent unnamed widget pool created in the calling procedure unless it creates an unnamed pool of its own. When execution of a routine ends, or it goes out of scope, any unnamed pools created in the routine are automatically deleted. Because a persistent procedure goes out of scope only when it is explicitly deleted, an unnamed widget pool created in one can persist as long as the procedure does.

You might use an unnamed pool to ensure that all objects created in the default pool in a procedure you run are deleted when that procedure returns or goes out of scope, as in this example:

CREATE WIDGET-POOL. RUN subprocedure.p. DELETE WIDGET-POOL.

In this example, the CREATE WIDGET-POOL statement creates a new default pool. Any objects created in the default pool within subprocedure.p are placed in this pool. After subprocedure.p completes, the pool is deleted along with any objects subprocedure.p might have created.

On the other hand, in a persistent procedure, you can use an unnamed pool to ensure that dynamic objects are not deleted after the procedure returns from its main block. Otherwise, if the calling procedure deletes the pool that was current when it ran the persistent procedure, it also deletes any dynamic objects for the persistent context.